大概在2018年的時候，開始認識敏捷。會想要認識敏捷，其實也是服務的公司碰到了一定程度的發展瓶頸。

那時候公司正處在一個快速發展期，有許多的工作排隊需要完成，進入了一個專案地獄的狀況。一方的論戰認為人力不夠補人就好，但也有主管認為這樣下去也不是辦法，因此在尋找如何提高人力效能的方式。其中的一條線就是開始認識敏捷這樣的方法論。

後來不少團隊紛紛導入敏捷的方法，甚至整個主管高層也邀請了講師認真了解敏捷的精神。有些團隊堅持了兩三年，至今仍運作著，但也不少團隊也適應不良，紛紛更換了專案進行的方法。當然也有不少團隊有了前車之鑑，採取迂迴的方式，逐步進推。

當時，我與幾個資深主管討論起敏捷的話題，討論出幾個非常難以解決的致命問題，導致敏捷的幾個關鍵要素似乎無法滿足。像是PO的角色在公司幾乎不可能滿足、公司內功能部門拆很細等等。而我的後端主管也提出了一個特殊的觀點，公司各部門內技術能力良莠不齊，甚至都在靠資深工程師吃下工作，但敏捷的工作方式會非常需要對等的工作能力，因此要推行起來會非常的困難。

左思右想，如果硬套入敏捷的流程在眼前的這些工程師身上，大概也不會有好下場吧。但我自己認為敏捷仍有幾個非常重要的精神，那就不如先把這些東西落實一陣子再說吧:

1.透明度。我使用的專案管理工具，其實就只是一個todolist。這個工作清單基本上是開放在google excel上，團隊內部只要知道網址的，都可以看的到我所有關注的專案。專案下來時，我會盡可能地說明整個來龍去脈，以及我所看到的戰略價值。會議時間一定提早約，請假都讓所有人知道。

2.使用者故事。在內部說明功能的過程中，我要求我自己，以及專案的團隊都要以「身為<角色>，我想要使用<功能>，達到<目的>」來跟RD團隊溝通。我發現這樣的陳述句，幫助對於商業角色較為陌生的工程師理解功能如何被使用，用一個使用情境去框出功能使用的方式，反推讓工程師知道功能範圍，即便不用訂出功能細節，工程師也能依照經驗開發出適合的功能。

到後來，當我只要說出功能需求是來自於哪個單位時，同仁大概就能快速的抓到需求，甚至可以提案應該怎麼做，達到我所碰到的流程難題。

3.群體Demo驗收工作。在團隊的作業中常常面對一個很有趣的狀況:前端說他做好了，後端也說他做好了，但是合起來的東西卻是壞掉的。早期前後端兩個團隊都還在吵架，但是當直接告訴團隊，我就是要在什麼時候看到可以Demo的進度時，慢慢兩邊團隊重新調整節奏，逐漸調整工作週期，慢慢都能夠在時間內完成串接，做出整個故事完整的操作流程。

"做好了"的定義，在單兵作戰底下視角，大概都是停留在自己的部分完成了，但主管要的"做好了"其實是要看到整體的整合完整的狀況。而整合，才是大家會額外花時間與吵架的階段。就算不管吵架，還要額外花時間才能整合完成，這個狀況就是為什麼專案會一直延宕的原因。

4.公開感謝。因為是技術出身的專案管理人，我一直期望工程師多少要補上專案思維。因此只要技術同仁提出了專案上思考不周的地方，我一定會公開感謝同仁主動的思考題問。

團隊即便人數多，但是大部分的人還是單兵認領任務後作戰，沒有進入真正的團隊運作的經驗。我的想法，就是透過公開的感謝，讓當事人知道自己的主動思考提出問題，是可以得到正面回應甚至得到主管的感謝，同時間也讓其他人知道，這樣才是一個團隊互相幫補的互動過程。

上面的這四點，其實在其他團隊建立或者專案管理流程中都會被提到，只是這四點剛好在敏捷開發的流程中都被提及。所選擇的這四個面向，算是當初整個團隊文化中缺很大的部分，不管在心理層面還是在時間管理務實的層面來說，都是相當不足的。運作一年多後，加上前端團隊內有些人也努力的落實其他敏捷的實踐，後端團隊實踐"天下武功唯快不破"的概念，兩邊共同走出自己的路，但卻又能合作愉快!

PS. 團隊的強壯並不是作對一件事兩件事就能達成，因此沒有人能單獨居功。所有的成功，都是大家做對的多做錯的少累積下來的。